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REMARKS 

Claims 1-31 are pending in the present application. Claim$ 1, 3, 13, 27, and 30 
were amended at the request of the examiner to correct informalities. Reconsideration of 
the claims is respectfully requested. 

*• 35 U.S-C $ 102. Anticipati on, Claims 1. 4. 5. 9-10, 13. 18. 21-22, 26-27 and 30-31 

The examiner has rejected claims 1, 4, 5, 9-10, 13, 18, 21-22, 26-27 and 30-31 
under 35 U.S.C § 102 as being anticipated by 4< Hot!NEWstujff; McAfee: Antivirus 
software for handhclds" to Meikle. This rejection is respectfully traversed. 
With regard to claims 1, 1 8, 30, and 3 1, the examiner states: 

As per claims 1, 18, 30 and 31 , Meikle teaches a method/data 
processing system/computer program product for preventing exchange of 
viruses, comprising: 

Maintaining preexisting content for a device in a first location (the 
handhelds in Meikle maintain preexisting content which is to be 
synchronized with the content on a pc); placing new content associated 
with the device in a second location (the new content is on the pc in 
Meikle), wherein the new content is an update to the preexisting content 
(Meikle says that the operation is a synchronization. This constitutes an 
update to preexisting content); combining the preexisting content and the 
new content in a third location to form merged content and performing a 
check for viruses on the merged content prior to performing a transfer of 
the new content (prior to the completion of the synchronization the pc 
scans content located on the handheld by uploading it, and then the 
synchronized/merged content is uploaded to the handheld). 

(Office Action dated January 29, 2004, pages 3-4). 

A prior art reference anticipates the claimed invention under 35 U.S.C. §102 only 
if every element of a claimed invention is identically shown in that single reference, 
arranged as they are in the claims. In reBond, 910 F.2d 831, 832, 15 U.S.P.Q.2d 1566, 
1567 (Fed. Cir. 1990). The Meikle reference cited by the Examiner does not anticipate the 
present invention as recited in claim 1, because Meikle foils to teach each and every 
element of claim 1. . Amended independent claim 1, which is representative of independent 
claims 10, 13, 18, 27, 30, and 31, reads as follows; 



Page 7 of 13 
Dawson, Jr. er al. - 09/692,988 



PAGE 9/15 * RCVD AT 312912004 1 1 :33:08 AM [Eastern Standard Time] * SVR:USPT0-EFXRF-1/3 * DN1S:8729306 * CSID:9723672002 * DURATION (mm-ss):04-40 



03/29/2804 10:34 9723672002 CYC PAGE 10 



1 . A method in a data processing system for preventing 
exchange of viruses, the method comprising: 

tnaintaining preexisting content for a device in a first location; 

placing new content associated with the device in a second 
location, wherein the new content is an update to the preexisting content; 

combining the preexisting content and the new content in a third 
location to form merged content; and 

perfonning a check for viruses on the merged content prior to 
performing a transfer of the new content. 

Claim 1 of the present invention recites the features of combining preexisting 
content and the new content in a third location to form merged content and perfonning a 
check for viruses on the merged content prior to performing a transfer of the new content. 
The step of combining preexisting content and the new content in a third location to form 
merged content is used to protect clients and servers from exchanging viruses via 
synchronization. The present invention recognizes that it is possible for a server to 
receive incremental updates that are infected with viruses that contain two or more parts, 
wherein the individual parts themselves are harmless. However, when the parts are 
compiled, the aggregate of the parts results in a virus. The following cited section in the 
Specification describes the basis for merging the preexisting content and the new content 
in a third location to detect such aggregate viruses in the manner recited in claim 1 : 

The present invention provides a method, apparatus, and computer 
implemented instructions for protecting clients and servers from 
exchanging viruses. The present invention recognizes that many clients, 
such as pervasive devices, communicate with servers via synchronization. 
This type of communication results in incremental updates to data or 
software being stored on a server for a client With this situation, it is 
possible for a virus to contain two or more parts in which the individual 
parts are harmless. When all of the parts are put together, however, the 
aggregate results in a virus. With incremental updates, latent viruses, such 
as these, may be propagated to servers and other clients. 

The mechanism of the present invention eliminates these types of 
threats of introducing and spreading viruses. This mechanism is 
especially useful for clients that use a server as a primary means of 
communication* Updates or additions to data or software for a client are 
not sent to a client or stored on a server with existing data for the client 
until the union of this data is tested for the presence of a virus. 
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{Specification, page 12, line 17 to page 13, line ] 1). As is described above, the 
preexisting content and the new content are combined in a merge area (third location) on 
the server prior to transferring the updates to the client or storing the updates on the 
server. The merged content is analyzed to determine whether a virus is present in the 
combined or merged content. Only if a virus is absent does the merged content get stored 
or are sent to the client. As a result, infected data, including aggregate viruses, maybe 
detected and disinfected prior to that content reaching its destination. 

Meikle does not teach the feature of combining the preexisting content and the 
new content in a third location to foim merged content, as recited in claim 1. Instead, 
Meikle teaches using antivirus software on a desktop computer to scan a handheld device 
to detect known viruses, as described in the following passage: 

McAfee has begun offering antivirus software to protect devices from the 
nascent threat of bugs written for handheld computers. The new software 
-McAfee VirusScan Handheld keeps known viruses from being 
transmitted between a desktop computer and handheld devices running the 
Palm operating system, Symbian's EPOC operating system, and Windows 
CE or its successor, Pocket PC, said product marketing manager Ryan 
McGee. 

This product begins to address a new, largely unprotected domain where 
viruses could spread. Though limited by bare-bones operating systems, 
handhelds are gaining in power and popularity, and sellers are avidly 
pushing devices that connect wirelessly to the Internet. A virus in Spain 
called Timofonica already attacked some cell phones. 

However, the antivirus software doesn't yet run on the handheld itself 
Instead, it runs only on a desktop computer and scans the handheld device 
when files on the PC and handheld are synchronized, McGee said. That 
means the handheld is still open to virus transmission when it exchanges 
information directly with the Internet or with another handheld. 

F-Secure unveiled software two weeks ago that runs on EPOC, an 
operating system designed by a cell-phone maker consortium called 
Symbian for smart cell phones and other handheld devices. 

{Meikle, page 12-13). As can be seen from the passage above, there is no mention of 
combining preexisting content and new content to form merged data in a third location, 
as the Examiner asserts. The Meikle reference does not provide any detail as to how the 
virus scan of the device is perform ed, other than that the antivirus software "scans the 
handheld device". The synchronization of the files on the PC and handheld device in 
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Meikle does not include using a merged area on the PC to combine existing content and 
new content to form a merged content to scan for viruses . Meikle merely teaches that 
when a handheld device makes a synchronization request, the antivirus software present 
on a PC scans the handheld device. In other words, the Meikle merely teaches scanning 
the device content, but there is no teaching in Meikle of combining new content with 
preexisting content on the PC to form a merged content. In fact, the Meikle reference 
teaches exactly what the present invention is trying to prevent - the incremental update 
situation where a virus contains two or more parts in which the individual parts are 
harmless, but the aggregate of the parts results in a vims. 

Furthermore, Meikle fails to teach performing a check for viruses on the merged 
content prior to performing a transfer of the new content, as recited in claim 1. As stated 
before, Meikle does not teach combining preexisting content and new content in a third 
location to form merged content. Since Meikle does not teach forming merged content, it 
must follow that Meikle fails to teach performing a check for viruses on the merged 
content prior to performing a transfer of the new content. 

In view of the above, Meikle fails to teach each and every element of independent 
claim L Using antivirus software on a desktop computer to scan a handheld device when 
files on the PC and handheld are synchronized in Meikle does not teach the present 
invention's features of combining preexisting content and the new content in a third 
location to form merged content and performing a check for viruses on the merged 
content prior to performing a transfer of the new content. As a result, the Meilcle 
reference fails to anticipate independent claims 1, 10, 13, 18, 27, 30, and 31 of the present 
invention. 

Moreover, Meikle does not teach, suggest, or give any incentive to make the 
needed changes to reach the presently claimed invention. Meikle actually teaches away 
from the presently claimed invention because it merely teaches scanning the handheld 
device for viruses as opposed to first combining the new content with preexisting content 
on the PC to form a merged content and then performing a check for viruses on the 
merged content prior to performing a transfer of the new content in order to prevent the 
incremental update situation where a virus contains two or more parts in which the 
individual parts are harmless, but the aggregate of the parts results in a virus, as in the 
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presently claimed invention. Absent the examiner pointing out some teaching or 
incentive to implement Meikle and combining the new content with preexisting content 
on the PC to form a merged content and then performing a check for viruses on the 
merged content prior to performing a transfer of th e new content, one of ordinary skill in 
the art would not be led to modify Meikle to reach the present invention when the 
reference is examined as a whole. Absent some teaching, suggestion, or incentive to 
modify Meikle in this manner, the presently claimed invention can be reached only 
through an improper use of hindsight using the applicants' disclosure as a template to 
make the necessary changes to reach the claimed invention. 

Applicants submit that independent claims 1, 10, 13, 18, 27, 30, and 31 are not 
taught by Meikle. Claims 2-9, 1 1-12, 14-1 7, 19-26, and 28-29 arc dependent claims 
depending on independent claims 1, 10, 13, 18, and 27, respectively. Applicants have 
already demonstrated claims 1, 10, 13, 18, and 27 to be in condition for allowance. 
Applicants respectfully submit that claims 2-9, 1 H2, 14-17, 19-26, and 28-29 are also 
allowable, at least by virtue of their dependency on allowable claims. 

Therefore, the rejection of claims 1, 4, 5, 9-10, 13, 18, 21-22, 26-27 and 30-31 
under 35 U.S.Q § 102 has been overcome. 

IL 35 U.S,C $ 103, Obviousn ess, Claims 2- 3. 8, 11-12. 14-17* 19-20, 25, and 28-29 

The examiner has rejected claims 2, 3, 8, 11-12, 14-17, 19-20, 25, and 28-29 
under 35 tLS.C § 103 as being unpatentable over HotlNEWstuff: McAfee: Antivirus 
Software for haudhelds to Meikle. This rejection is respectfully traversed. 

The Meikle reference still does not teach or suggest al] the claim limitations in 
dependent claims 2, 3, 8, 11-12, 14-17, 19-20, 25, and 28-29. Claims 2, 3, 8, 1 1-12, 14- 
17, 19-20, 25, and 28-29 are dependent claims depending from claims 1, 10, 13, 18, and 
27, respectively. Applicants have already demonstrated claims 1, 10, 13, 18, and 27 to be 
in condition for allowance. Consequently, claims 2, 3, 8, 1 1-12, 14-1 7, 19-20, 25, and 
28-29 are patentable over the Meikle reference because the features relied upon as being 
taught in the Meikle reference are not taught or suggested by that reference, as explained 
in the response to the rejection of independent claim 1 above. Thus, applicants 
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respectfully submit that claims 2, 3, 8, 1 1-12, 14-17, 19-20, 25, and 28-29 are also 
allowable, at least by virtue of their dependency on allowable claims. 

Therefore, the rejection of claims 2, 3, 8, 11-12, 14-17, 19-20, 25, and 28-29 
under 35 U.S.C § 103 has been overcome. 

HI. 35 V.S.C. S 103» Obvionsness. Claims 6. 7. 23, and 24 

The examiner has rejected claims 6, 7, 23, and 24 under 35 U.S.C, § 103 as being 
unpatentable over Hot!NEWstuff: McAfee: Antivirus Software for handhelds to Meikle, 
in view.of PC WORLD: Do Handhelds Need Virus Protection? to Silver. This rejection 
is respectfully traversed. 

The combination of Meikle and Silver fail to teach or suggest the present 
invention as recited in claims 6, 7, 23, and 24. Although Silver may teach storing an 
antivirus application on the host PC, {Silver, page 1 under "Alternative Approaches"), the 
Meikle reference still does not teach or suggest all the claim limitations in claims 6, 7, 23, 
and 24, as argued in the response to the rejection of claim 1 above. Claims 6, 7, 23, and 
24 are patentable over the cited references because the combination of th e Meikle 
reference with Silver would not reach the presently claimed invention. The features 
relied upon as being taught in the Meikle reference are not taught or suggested by that 
reference, as explained above. As a result, a combination of these references would not 
reach the claimed invention, in claims 6, 7, 23, and 24. 

Therefore, the rejection of claims 6, 7, 23, and 24 under 35 U.S.C. § 103 has been 
overcome. 
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IV. Conclusion 

It is respectfully urged that the subject application is patentable over the cited 
references and is now in condition for allowance. 

The examiner is invited to call the undersigned at the below-listed telephone 
number if in the opinion of the examiner such a telephone conference would expedite or 
aid the prosecution and examination of this application. 



DATE: 




Respectfully submitted, 




Registration No. 51.886 
Carstens, Yee & Cahoon, LLP. 
P.O. Box 802334 
Dallas, Texas 75380 
(972) 367-2001 

ATTORNEY FOR APPLICANTS 
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